@94bryanr, does this resolve the issue you were seeing?

Unfortunately, I still see the visual artifact of nothing rendered below a certain line when the resolution is increased. This is with the new config DebugLayers set to none and MemoryHints set to Performance.

We probably need code which reproduces this issue to be able to help

Just editing the simple example to fill a shape of a large size, say 8000x8000, will demonstrate the problem when rendering to a window roughly larger than 4096x4096 (it really depends on the area). At some point, new tiles stop being rendered. Though if you're unlucky, you get a compute shader timeout instead.

If I had to guess I'd say that the limit is 256 x 256 tiles.

Just done some experiments, and have been able to reproduce, and isolated this to us only supporting 256 bins. I've opened #680 to track this.

However, the issue @94bryanr seems to be a separate issue again, interestingly.
We need a minimal reproduction for that issue as well. I have explained why it looks like a different issue in #680.

There is a reason we don't have a check in path_tiling, though it's possible I missed something. Essentially, the number of tiles written in path_tiling should always be less than or equal to the count determined in the path_count stage. That, in turn, is checked against the buffer size in coarse, and then downstream of that, path_tiling_setup zeroes out the dispatch of path_tiling, so effectively it doesn't run.

If my analysis is correct, then we probably should close this without merging, but I am very open to an argument that something might still go wrong that this check would mitigate.

This was discussed in #gpu > Segments and seg_counts buffer sizes. We decided that follow-up work is to make the segments and seg_counts buffer use the same capacity (even though they have different bumps).

I'll do that in a different PR.